So the trouble I have with this change is that it muddies the waters... What if it's to be an expression now? Like http.response_code - 12 ? The white spaces matter now?
That being said I don't think we'd ever support that (very example if only 🤣 ). That being said I already hated having the . in there... tho I thought you could have argued it remained an identifier for "something" to resolve...

So anyways, I won't necessarily block this from happening, but I wonder if sanitizing the variable names/identifiers wouldn't be slightly more desirable.

We don’t necessarily need - nor /. Intuitively, we went with these characters because the Limitador identifiers that the RateLimitPolicy controller generates come straight from qualified limit definitions stated in Kubernetes resources, where the / char is used as the namespace-resource separator and the - char is often used in the names of the resources. We first thought that by keeping such format we'd favour readability (even though we’re here talking about internal values of internal resources that hardly will be inspected by humans).

In the end, all we need are unique limit identifiers. Readability and easy referencing of those bits of configuration across resources are a plus. In fact, while we are using the namespaced name of the RateLimitPolicy resource in the namespace field of the rate limit definition, only the name of the limit for this particular identifier suffices. Replacing the unsupported characters there won't be a problem.

All that to say that we don't need this PR. We can fix some other way in the RateLimitPolicy controller, in https://github.com/kuadrant/kuadrant-operator.

Thanks @didierofrivia and @alexsnaps! I think we can close this.